home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / maillist / 94-05.Z / 94-05 / 000208_news@bigblue.oit.unc.edu_Sun May 15 22:44:24 1994.msg < prev    next >
Internet Message Format  |  1994-05-31  |  11KB

  1. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AA18578; Sun, 15 May 1994 18:15:14 -0400
  3. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  4.           id AA34008; Sun, 15 May 1994 17:44:36 -0400
  5. Received: from GATEWAY by bigblue with netnews
  6.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  7. To: winsock@sunsite.unc.edu
  8. Date: Sun, 15 May 1994 22:44:24 GMT
  9. From: leyx0006@gold.tc.umn.edu (Bob Zimbinski)
  10. Message-Id: <leyx0006.3.00135767@gold.tc.umn.edu>
  11. Organization: University of Minnesota, Twin Cities
  12. Sender: ses
  13. References: <leyx0006.2.0043D43D@gold.tc.umn.edu>, <patlee.506.0012F66D@panix.com>
  14. Subject: Re: Stabilizing Win Mosaic 2b4
  15.  
  16. In article <patlee.506.0012F66D@panix.com> patlee@panix.com (Patrick Lee) writes:
  17. >From: patlee@panix.com (Patrick Lee)
  18. >Subject: Re: Stabilizing Win Mosaic 2b4
  19. >Date: Sun, 15 May 1994 08:38:58 EDT
  20.  
  21. >In article <leyx0006.2.0043D43D@gold.tc.umn.edu> leyx0006@gold.tc.umn.edu (Bob Zimbinski) writes:
  22.  
  23.  
  24. >Make sure you are running it on a 486 with 8 MB of RAM and a good nice swap 
  25. >file ... There's also seems to be problem with Mosaic not returning resources 
  26. >back to Windows after it exits.
  27. I'm running a 486/33 with 16 MB of RAM and a huge stinking swap file.  I've 
  28. tried it with no other applications running and I've gone over the .ini file 
  29. several times.  This is frustrating...
  30.  
  31. Bob Zimbinski
  32. leyx0006@gold.tc.umn.edu
  33. From news@bigblue.oit.unc.edu Sun May 15 18:45:13 1994
  34. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  35.           id AA22643; Sun, 15 May 1994 18:45:13 -0400
  36. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  37.           id AA35336; Sun, 15 May 1994 18:34:35 -0400
  38. Received: from GATEWAY by bigblue with netnews
  39.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  40. To: winsock@sunsite.unc.edu
  41. Date: Sun, 15 May 1994 17:20:02
  42. From: tnert@utxsvs.cc.utexas.edu (Trent Stevens)
  43. Message-Id: <tnert.735.00115602@utxsvs.cc.utexas.edu>
  44. Organization: UT Austin
  45. Sender: ses
  46. References: <tnert.734.000FF6E9@utxsvs.cc.utexas.edu>
  47. Subject: Re: IVC Users--CALL ME!  (Apologies to Deborah Harry)
  48.  
  49. In article <tnert.734.000FF6E9@utxsvs.cc.utexas.edu> tnert@utxsvs.cc.utexas.edu (Trent Stevens) writes:
  50. >From: tnert@utxsvs.cc.utexas.edu (Trent Stevens)
  51. >Subject: IVC Users--CALL ME!  (Apologies to Deborah Harry)
  52. >Date: Sun, 15 May 1994 15:57:45
  53.  
  54. >OK, now that I've gotten your attention:  has anyone gotten IVC to work yet?  
  55. >If so, please give me a call at 128.83.204.17 (the SLIP address will only be 
  56. >good until 7PM EDT).  I'm using Chameleon, so there shouldn't be any major 
  57. >problems on this end.  
  58.  
  59. Sorry for the clichi, but I have to say:  NOT!  Windows apparently was running 
  60. low on resources, so I had to reboot (after two IVC GPFs).  I'm up again for 
  61. the moment, so if you'd like to try (again?), the number is 128.83.128.80.  
  62.  
  63. Thanks again for your help and your patience!
  64.  
  65. Trent Stevens  tnert@bisque.cc.utexas.edu
  66. From news@bigblue.oit.unc.edu Tue May 13 19:59:38 1994
  67. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  68.           id AA22650; Sun, 15 May 1994 18:45:15 -0400
  69. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  70.           id AA23506; Sun, 15 May 1994 18:28:30 -0400
  71. Received: from GATEWAY by bigblue with netnews
  72.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  73. To: winsock@sunsite.unc.edu
  74. Date: 13 May 1994 19:59:38 GMT
  75. From: poffen@San-Jose.ate.slb.com (Russ Poffenberger)
  76. Message-Id: <2r0m7a$lf1@k2.San-Jose.ate.slb.com>
  77. Organization: Schlumberger Technologies, ATE division, San Jose, Ca.
  78. Sender: ses
  79. References: <1994Apr22.161426.145506@ans.net>, <matt.10.2DCAB5B1@sc1.tamu.edu>, <CpqvDB.MpC@cyanamid.uucp>
  80. Subject: Re: 32 bit access with SCSI no available. Hunh? was Re: Win Mosaic alpha 4 (my fix)
  81.  
  82. Vic Kamhi (kamhiv@pt.cyanamid.com) wrote:
  83.  
  84. : In article <trumpet-support.171.2DD2E384@petros.psychol.utas.edu.au>, 
  85. : > 
  86. : > My questions are... 
  87. : > 
  88. : > Can you buy comparable large hard disks for IDE controllers?  
  89. : > At the same price?
  90. : > Are the driver problems we are experiencing ever going to be resolved?
  91. : > 
  92. : > Peter
  93. : > 
  94.  
  95. : Apparently Enhanced IDE drives are on their way. The claims are:
  96. : 1) bigger drives supported without kludges
  97. : 2) more drives supported (4 instead of 2)
  98. : 3) non-disk devices (i.e., CD-ROMS) supported
  99. : 4) faster (near SCSI) speeds
  100. : Reports in the trade press (take that for what it's worth!) say that you
  101. : should be seeing the Enhanced IDE stuff by this fall in many high-end
  102. : (i.e., 486DX3 and Pentium) systems. They say that Phillips (?) will be
  103. : introducing an IDE CD-ROM almost as you read this. 
  104.  
  105. : Except that SCSI still can support more devices per chain (but many don't
  106. : need 6!), more types of devices (scanners, tape drives; but, again, not
  107. : everybody needs these), and will still be inherantly faster (except, of
  108. : course, for the proviso about 32-bit under Windows), this new IDE system
  109. : might be just what the doctor ordered for many!
  110.  
  111. : --VIC
  112.  
  113. It still lacks the multitasking features that SCSI has. Under a true multi-
  114. tasking OS like UNIX, OS/2 or NT, SCSI can make a big difference.
  115.  
  116. Russ Poffenberger               DOMAIN: poffen@San-Jose.ate.slb.com
  117. Schlumberger Technologies ATE   UUCP:   {uunet,decwrl,amdahl}!sjsca4!poffen
  118. 1601 Technology Drive        CIS:    72401,276
  119. San Jose, Ca. 95110             Voice: (408)437-5254  FAX: (408)437-5246
  120. From news@bigblue.oit.unc.edu Tue May 13 19:54:40 1994
  121. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  122.           id AA22657; Sun, 15 May 1994 18:45:16 -0400
  123. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  124.           id AA23505; Sun, 15 May 1994 18:28:29 -0400
  125. Received: from GATEWAY by bigblue with netnews
  126.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  127. To: winsock@sunsite.unc.edu
  128. Date: 13 May 1994 19:54:40 GMT
  129. From: poffen@San-Jose.ate.slb.com (Russ Poffenberger)
  130. Message-Id: <2r0lu0$lf1@k2.San-Jose.ate.slb.com>
  131. Organization: Schlumberger Technologies, ATE division, San Jose, Ca.
  132. Sender: ses
  133. References: <CppIL6.vK@nntpa.cb.att.com>, <2quet0$8u3@bmerha64.bnr.ca>, <arnsteinCpr4MC.HL5@netcom.com>
  134. Subject: Re: 32 bit access with SCSI not avail. -> Adaptec questions.
  135.  
  136. David Arnstein (arnstein@netcom.com) wrote:
  137. : In article <2quet0$8u3@bmerha64.bnr.ca>, Jeff Hayes <jjhayes@bnr.ca> wrote:
  138. : >
  139. : >_]What you desperately need is an ASPI driver that either (a) supports
  140. : >_]the virtual DMA interface directly, or (b) provides the necessary
  141. : >_]buffering itself.  This will allow you to get rid of the SMARTDRV
  142. : >_]/DOUBLE_BUFFER line in your CONFIG.SYS. 
  143. : >    Adaptec docs say to remove the /DOUBLE_BUFFER, set VirtualHDIRQ=off
  144. : >in system.ini to make everything happy in Windows.
  145. : >
  146. : >_]Adaptec's ASPI4DOS has a switch to provide the necessary
  147. : >_]buffering itself
  148. : >    I have the Adaptec docs here in front of me and there is no
  149. : >switch to enable buffering in aspi4dos.  Neither do any of the other 3
  150. : >drivers.  Hummm.
  151. : >
  152. : >    So...
  153. : >
  154. : >    The questions to answer (Adaptec's docs do not) are:
  155. : >
  156. : >    Do the Adaptec drivers support VDMA?
  157. : >    Do they do there own buffering?
  158. : >    Is there buffering cache on the ctlr board?
  159.  
  160. : Just listen to all this complexity!  If you have the guts, do a
  161. : quantitative comparison of speed of your SCSI nightmare with an IDE
  162. : drive - while running Windows 3.1.  Have you gained any speed?
  163.  
  164. Load an ASPI driver and compare. Probably little difference. Now try comparing
  165. a SCSI based system with multiple devices (disks, tapes, CDROM) on a true
  166. multitasking OS like NT or OS/2 against an IDE drive, and see which one is
  167. faster.
  168.  
  169. Russ Poffenberger               DOMAIN: poffen@San-Jose.ate.slb.com
  170. Schlumberger Technologies ATE   UUCP:   {uunet,decwrl,amdahl}!sjsca4!poffen
  171. 1601 Technology Drive        CIS:    72401,276
  172. San Jose, Ca. 95110             Voice: (408)437-5254  FAX: (408)437-5246
  173. From rcq@mailserv-D.ftp.com Sun May 15 15:30:47 1994
  174. Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  175.           id AA28974; Sun, 15 May 1994 19:32:11 -0400
  176. Received: from ftp.com by ftp.com  ; Sun, 15 May 1994 19:32:10 -0400
  177. Received: from mailserv-D.ftp.com by ftp.com  ; Sun, 15 May 1994 19:32:10 -0400
  178. Received: from rcq.sidearm.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
  179.     id AA13016; Sun, 15 May 94 19:30:47 EDT
  180. Date: Sun, 15 May 94 19:30:47 EDT
  181. Message-Id: <9405152330.AA13016@mailserv-D.ftp.com>
  182. To: emw@netcom.com
  183. Subject: Re: questions re closesocket(), shutdown(), etc
  184. From: rcq@ftp.com  (Bob Quinn)
  185. Reply-To: rcq@ftp.com
  186. Cc: Multiple recipients of list <winsock@sunsite.unc.edu>
  187. Sender: rcq@mailserv-D.ftp.com
  188. Repository: mailserv-D.ftp.com, [message accepted at Sun May 15 19:30:41 1994]
  189. Originating-Client: sidearm.ftp.com
  190. Content-Length: 1828
  191.  
  192. >  When talking to the other side and you receive an error saying the
  193. >  connection was reset by peer, do you still need to shutdown and/or close
  194. >  the socket? How about if the connection is closed by the other side? I've
  195. >  read the spec and can't find anything definitive. Is it stack dependent?
  196.  
  197. After a TCP socket receives a reset--at initial connection attempt
  198. or while connection is active--you still need to call closesocket().
  199. You always need to call closesocket().  This function "releases the
  200. socket descriptor", and any associated resources (e.g. memory allo-
  201. cated for WinSock internal socket structures).  This requirement is
  202. *not* implementation dependent (i.e. it's universal).
  203.  
  204. You need not call shutdown() after receiving a reset, though
  205. it shouldn't cause a problem to do so.  It may fail with the
  206. WSAENOTCONN error, though this *is* implementation dependent.
  207. It might not fail, or it might return a different error.  Even
  208. though they're not listed for shutdown(), it would be legal for a
  209. WinSock to report either WSAECONNABORTED or WSAECONNRESET errors
  210. after such a failure from shutdown() (see section 3.3.4 Error
  211. Handling on page 16, for the caveat in the last paragraph).
  212.  
  213. After the other side initiates the graceful close of a connection,
  214. you need to call closesocket() (or shutdown()) to complete the
  215. close.  Unlike when your side initiates the close, in this case
  216. calling shutdown() before closesocket() should not be necessary.
  217. Because the other side already sent a <FIN>, you know they won't
  218. be sending any more data, and the main reason to call shutdown()
  219. (with "how=1") before closesocket() is to read any remaining data
  220. before releasing the socket.
  221.  
  222. Regards,
  223. --
  224.  Bob Quinn                                             rcq@ftp.com
  225.  FTP Software, Inc.                                No. Andover, MA